Wireless sensor networks are commonly used in environmental sensing and consist of nodes with embedded sensing and communication devices. Node hardware can be provided with small devices with sizes comparable to a quarter. Such networks can form the basis for “smart” environments in hospitals, conference rooms, homes, or on battlefields. Primary operations in wireless sensor networks (WSNs) can be environmental sensing and reporting to a base station, or relaying information to and from other nodes. Mobile Ad hoc Networks (MANETs) are infrastructure-less in nature, and require no pre-deployed communication set-up and such configurations can be used with WSNs. MANETs are self collaborative, and can automatically discover routes to a destination using intermediate nodes to route data to a destination not directly reachable using multiple short hops rather than a single hop from source to destination. This “short-hop” communication is a natural choice for WSNs since multiple short hops typically conserve energy for the source node and dissipate small amounts evenly at intermediate nodes. A pervasive computing set-up includes many individual components, and ad hoc networks are well suited for the necessary networking support. However, MANETs are challenged by the inherent dynamism of the network, demands on communication bandwidth and interference, and energy usage and network lifetime.
The basic network communication process consists of sending data from source to destination. An application at a source generates information that is encoded and transmitted to a destination where it is decoded by a destination application. This communication process can be logically partitioned into a definite sequence of events or actions, and individual entities then form “layers” of a communication “stack.” Traditionally, the communication process has been formally organized as the ISO-OSI reference model stack that includes seven layers from the Application Layer to the Physical Layer.
Application-specific communication protocols can be adapted to new uses such as in WSNs. For example, the use of the Internet architecture and its component protocols has grown rapidly, and Internet-based designs and protocols have been migrated to other applications such as WSNs. While Internet protocols are well suited to Internet use, Internet-based operation can be unsatisfactory with WSNs which have substantially different requirements. In addition, the individual modules designed for WSNs are often validated over a set of workloads that are thought to be representative of the entire application gamut of WSNs. This is not generally a valid assumption, since the application types and their requirements are extremely variable. Applications requirements range from point-to-point (P2P) to broadcast to anycast communications. Some applications demand reliable communication while others do not, and some have real-time time constraints (such as low latency) while others do not. Hence, it is inappropriate to assume that a given module performing over a particular workload or tuned to do well for one application can be successfully applied everywhere. Because of these variable requirements, it is challenging to come up with a single module that handles all application types.
Accordingly, methods and apparatus are needed that can identify features needed in a suitable stack so that these features can be included in stack designs rather than merely accepting features obtained by protocol migration from the Internet or other networks (such stack designs are referred to hereinafter as “stack aware architectures”). In addition, Internet-based designs should be validated for “stack aware” properties. Furthermore, a taxonomy of application types needs to be established for WSNs that lists functions that each application type demands. A dynamic stack that maps requirements for an application to available modules on a per packet basis based on preamble processing of the stack is needed as well. According to representative embodiments, a communication system in a wireless sensor network adapted to provide a communication link between a plurality of nodes includes a protocol stack encapsulating a plurality of fundamental network protocol layers that correspond to an open system interconnection (OSI) model, wherein each of the layers comprises a plurality of modules. The communication system further includes a preamble module adapted for defining a set of requirements for at least one application. In some examples, the communication system includes a communication module adapted for communicating data between the plurality of nodes by selecting one or more modules from at least one of the layers of the stack to form a combination of modules indicative of the preamble module defined, wherein the combination is based on quality of service (QoS) desired by the at least one application.
According to additional examples, methods for wireless sensor networks adapted to provide a communication link between a plurality of nodes comprise a protocol stack encapsulating a plurality of fundamental network protocol layers that correspond to an open system interconnection (OSI) model, wherein each of the layers comprises a plurality of modules. The methods include defining a set of requirements for at least one application using a preamble module. The methods further include communicating data between the plurality of nodes by selecting one or more modules from at least one of the layers of the stack to form a combination of modules indicative of the preamble module, wherein the combination is based on quality of service (QoS) selected for the at least one application. The selection of the one or more modules for the at least one layer can be based on the selected modules in preceding layers and available modules in succeeding layers.
Wireless sensor network nodes comprise a preamble module adapted for defining a set of requirements for communication of a data packet by an application and a protocol lookup module configured to identify at least one component protocol based on the defined set of requirements. A protocol assembler is configured to assemble a protocol stack based on selected protocol components and process the data packet based on the component protocol and deliver the processed data packet to a scheduler. In some examples, the preamble module is configured to define the set of requirements by establishing a preamble that is communicated with the data packet. In other examples, the preamble is defined as a byte that includes bits associated with data type, data transfer reliability, and data transfer delay, respectively. In further embodiments, the protocol lookup table is configured to store protocol characteristics in association with bits of the preamble byte. In further examples, the preamble module is configured to assign at least one of an acknowledgement flag, a link estimate flag, a data type flag, a retransmission flag, an application type, a real-time flag, or a load balance flag to a preamble byte. In other embodiments, the protocol lookup includes a memory configured to store application requirements for a plurality of applications.
Wireless network nodes comprise a processor configured to receive an indication of a quality of service (QoS) requested by an application and determine values of at least one bit of a preamble byte based on the QoS, and a transmitter configured to transmit a data packet established by the application and the preamble byte. In other examples, the processor is configured to receive an estimate of network congestion at least one network node, and the value of at least one bit of the preamble byte is based on the estimate. In still further embodiments, the processor is configured to receive an indication of available protocol components exclusive of the selected component, and at least a second preamble bit value is determined based on the indication.
Methods comprise associating at least one network preference with a data payload to be transmitted, and attaching at least one preamble bit to the data payload, wherein a value of the at least one preamble bit is based on the network preference. The at least one preamble bit and the data payload are then transmitted. In additional examples, at least one protocol component is selected based on the at least one preamble bit. In other embodiments, the data payload and the at least one preamble bit are transmitted to the network node based on the selected protocol component. In further examples, the preamble is a byte that includes preamble bits associated with data type, data reliability, and data delivery delay, and the preamble byte is attached to the data payload. In still further examples, the preamble bit and the data payload are transmitted by a network application and a plurality of protocol components are selected based on the preamble byte. In some examples, the protocol component is selected based on a protocol component look-up table. In other examples, the selected protocol component is selected based on a preferred energy use at least one network node or based on congestion at least one network node. In one example, the selected protocol component is UDP.
In additional examples, the at least one network preference is associated with a subsequent data payload that is substantially similar to the transmitted data payload, and the at least one preamble bit is attached to the subsequent data payload. At least one subsequent protocol component is selected that is different than the protocol component associated with transmission of the transmitted data payload. In further examples, the subsequent data payload is transmitted based on the subsequent protocol component. In other examples, at least one bit of the preamble byte is assigned by an application associated with the data payload. In further examples, at least a second protocol component is selected based on the selected protocol component and the preamble byte.
In some examples, a tangible computer program product includes computer-executable instructions for providing a communication link between a plurality of nodes. A protocol stack encapsulating a plurality of network protocol layers comprising a plurality of modules is selected based on requirements requested by an application. In particular examples, the requirements are associated with a requested quality of service (QoS), and least one of the plurality of modules is selected based on a previously selected module or a set of modules available to be selected for a different protocol layer. In some examples, a selected module is replaced in the protocol stack in response to a change in the QoS requested by the application or in response to network congestion or power consumption. In other examples, the at least one application is characterized to produce an associated preamble. In other examples, a selected protocol component is replaced by a different protocol component in response to a request for data transmission by the application. In some examples, the application QoS or other application requirements are provided based on user input or an application type. In some examples, a preamble is assigned based one or more categories associated with real-time data transmission requests.
These and other features, aspects, and advantages of the technology are described in detail below with reference to the accompanying drawings.